Lecture 14 – SVN, Mercury and Git

📚 Week 5 · Unit III · Lecture 14

SVN, Mercury (Mercurial)
& Git

A practical deep dive into the three most influential Version Control Systems. We'll explore their architecture, core concepts, and see hands-on examples of everyday commands.

Dr. Mohsin Furkh DarSchool of Computer Sciences

DateMon, 06 Jul 2026 · 11:00 AM – 12:00 PM

ProgrammeBTech CSE – Summer Semester

Today's Agenda

1

Recap — History of SCM

2

Subversion (SVN) — Architecture & Workflow

3

SVN — Hands-on Commands

4

Mercurial (Mercury) — The Python DVCS Alternative

5

Git — Architecture & The Directed Acyclic Graph

6

Git — Hands-on Commands & Final Comparison

Recap

Where We Left Off

✅
Lecture 13: We traced the history of SCM from SCCS and RCS (local) to CVS and SVN (centralized) to Git and Mercurial (distributed). We discussed why DVCS replaced Centralized VCS, highlighting the speed, offline capabilities, and data safety of systems like Git.

🎯
Today: We are looking at the "Big Three" of modern SCM history: SVN (the champion of the centralized era), Mercurial (often called "Mercury," Git's early distributed rival), and Git (the undisputed winner). We'll look at how they work under the hood and typical command flows.

🏢

SVN
Centralized

💧

Mercurial
Distributed (Easy)

🔀

Git
Distributed (Fast)

Subversion

SVN Overview

🏛️

Apache Subversion (SVN) is a centralized version control system created in 2000 by CollabNet as a successor to CVS. Its goal was simple: "CVS done right." It dominated the industry until Git took over.

🎯

Central Repository

A single server holds the master repository. Clients only have a "working copy" of a specific version, plus hidden .svn folders to track local changes before committing.

🔢

Global Revision Numbers

Commits are sequential and global. If the repo is at revision 100, and you commit, the entire repository moves to revision 101. (Unlike Git's SHA hashes).

📁

Branches = Directories

SVN has no native "branch" object. A branch is literally a directory copy (e.g., copying /trunk to /branches/feature1). SVN makes this a "cheap copy" under the hood.

Architecture

The SVN Standard Directory Layout

Because SVN treats branches and tags as simple directory copies, the community adopted a standard folder structure that almost all SVN repositories follow.

Standard Layout

/my-project/
├── trunk/        # Main development line
│   ├── src/
│   └── README.txt
├── branches/     # Ongoing feature work
│   ├── feature_x/
│   └── bugfix_y/
└── tags/         # Stable releases (read-only)
    ├── v1.0/
    └── v1.1/
            

Key Concepts

trunk: Equivalent to Git's main or master. Where stable, shared development happens.
branches: Copies of trunk used for isolated work. Must be merged back to trunk.
tags: Snapshots of the code at a specific time (e.g., a release). By convention, you never commit to a tag folder.

⚠️
The Network Bottleneck: Because history lives only on the server, running svn log to see history, or svn diff against older versions, requires a network call to the server. If the server is down, or you have no Wi-Fi, you cannot commit, view history, or switch branches.

Hands-On

Everyday SVN Commands

          # 1. Get a working copy from the server (like git clone)

          $ svn checkout https://svn.example.com/repo/trunk my-project

          # 2. Update local copy with latest changes from server (like git pull)

          $ svn update

          # 3. Add a new file to tracking

          $ svn add new_feature.js

          # 4. View local changes

          $ svn status     # Shows M (Modified), A (Added), etc.

          $ svn diff       # Shows line-by-line changes

          # 5. Commit changes TO THE SERVER (no local commit exists)

          $ svn commit -m "Added new feature"

          # 6. Create a branch (Notice it's just a server-side copy command)

          $ svn copy https://.../repo/trunk https://.../repo/branches/my-branch -m "Branching"

💡 The SVN Mindset

In SVN, Commit = Publish. When you type svn commit, your code goes straight to the central server and immediately affects everyone else when they svn update. This makes developers hesitant to commit broken or incomplete code, leading to huge, risky commits after weeks of local work.

Mercurial

Mercurial (Hg) Overview

💧

Mercurial (often called "Mercury", command line hg) is a Distributed Version Control System (DVCS) released in 2005 — just days after Git. It was written in Python and C, prioritizing ease of use, clean commands, and excellent cross-platform support (especially on Windows).

🧠

Clean Mental Model

Unlike Git, which exposes its complex internal plumbing to the user, Mercurial hides the complexity. Its command set is logical, predictable, and very easy to learn for SVN users.

🔒

Safe by Default

Mercurial believes history is sacred. By default, you cannot alter, rewrite, or delete published history (unlike Git's dangerous rebase or push -f).

🐍

Python Native

Being written mostly in Python made it highly extensible. It was chosen by massive Python-heavy organizations, most notably Facebook (who scaled it to handle their massive monorepo) and Mozilla.

Architecture

Mercurial Concepts

Because Mercurial is distributed like Git, you clone a full repository. However, its approach to branching and history is distinct.

Revisions & Hashes

Mercurial gives every commit a SHA-1 hash (like Git: b382d...).
But it also gives a local sequential number (e.g., 42).
This makes referencing commits easier locally, though numbers vary between developers' clones.

Branching Styles

Named Branches: Embedded permanently in the commit metadata. Good for long-lived releases.
Bookmarks: Movable pointers to commits (exactly how Git branches work).
Anonymous Branches: Just pull and commit; multiple "heads" form naturally.

📊
The Staging Area absence: One of the biggest differences from Git is that Mercurial has no index/staging area by default. When you type hg commit, it commits all modified tracked files immediately, feeling much more like SVN.

Hands-On

Everyday Mercurial (hg) Commands

          # 1. Clone a remote repository (gets the full history)

          $ hg clone https://hg.example.com/project

          # 2. View local changes

          $ hg status

          # 3. Add files and commit LOCALLY

          $ hg add new_file.txt

          $ hg commit -m "Added a new file"

          # 4. Fetch changes from the server and merge them into local work

          $ hg pull       # Brings down changesets

          $ hg update     # Updates working directory

          # (Or just use 'hg pull -u')

          # 5. Push local commits back to the central server

          $ hg push

💡 The DVCS Mindset

Notice the split: Commit is local, Push is remote. You can hg commit 50 times while offline on a train. Only when you are ready to share do you hg push to the team. This completely removes the fear of committing broken code.

Git

Git Overview

🔀

Git is the dominant DVCS, created by Linus Torvalds in 2005 to manage the Linux kernel. It is famously fast, highly flexible, and built around a brilliant data model (the DAG). However, it is also notorious for its steep learning curve and inconsistent command line interface.

⚡

Unmatched Speed

Written in C and optimized for local disk access. Branching, merging, and logging happen in milliseconds because they are purely local operations.

📦

Snapshots, not Diffs

SVN and Mercurial think of history as a list of file changes (deltas). Git thinks of history as a stream of complete mini-filesystems (snapshots).

🛠️

The Staging Area

Git introduces the "Index" or Staging Area. You must explicitly git add files to stage them before committing. This allows crafting precise, logical commits.

Architecture

The Three Trees & The DAG

To understand Git, you must understand its three states (trees) and how commits are linked.

Working Directory(Your files)

Staging Area / Index(git add)

Local Repository(git commit)

Remote Repo(git push)

Directed Acyclic Graph (DAG)

Every commit points to its parent(s).
A branch is just a lightweight, movable pointer to a specific commit.
HEAD is a special pointer indicating what you currently have checked out.
When you merge, Git walks back through the DAG to find the common ancestor.

History Rewriting

Unlike Mercurial, Git lets you rewrite history locally before pushing.
Commands like git rebase and git commit --amend allow you to clean up a messy local history.
Rule: Never rewrite history that has been pushed and shared.

Hands-On

Everyday Git Commands

          # 1. Clone a remote repository

          git clone https://github.com/user/repo.git

          # 2. Branching (Create and switch to a new branch)

          git checkout -b feature-login

          # (Modern alternative: git switch -c feature-login)

          # 3. Stage and Commit

          git add login.js               # Moves file to Staging Area

          git commit -m "Add login UI"   # Moves Staging to Local Repo

          # 4. Syncing with Remote

          git pull origin main           # Fetch and merge latest changes

          git push origin feature-login  # Send local branch to server

🔥
Git relies on "Remotes". In Git, origin is simply the default name given to the remote server you cloned from (like GitHub). Because Git is distributed, you could have multiple remotes (e.g., origin for the team server, upstream for an open-source project).

Comparison

SVN vs Mercurial vs Git

Feature	SVN	Mercurial (Hg)	Git
Architecture	Centralized	Distributed	Distributed
Storage Model	File diffs (deltas)	File diffs (deltas)	Snapshots
Branching	Heavy (Directory copies)	Lightweight	Lightweight (Pointers)
Staging Area	No	No (Direct commit)	Yes (The Index)
History Rewrite	No	Difficult (Safe by default)	Easy (Rebase, amend)
Learning Curve	Low	Low	High
Primary Language	C	Python	C

Industry Evolution

Why the World Left Centralized (SVN)

The transition from SVN to Git/Mercurial in the late 2000s fundamentally changed how developers work.

The SVN Pain Points

Fear of Committing: Commits broke the build for everyone. Developers hoarded code for weeks.
Merge Anxiety: SVN merges were so painful that teams actively avoided branching, leading to messy "trunk" code.
Network Reliance: A slow VPN or dropped connection halted all productivity.

The DVCS Liberation

Micro-commits: Commit locally every 5 minutes. Combine them later. Zero risk to the team.
Feature Branches: Cheap branches meant every tiny task got its own safe workspace.
The Pull Request: DVCS enabled the modern code-review workflow (fork → branch → PR → merge).

🚀 Impact on DevOps

DVCS made CI/CD possible. Because branching and merging became cheap and reliable, teams could use "Feature Branches". This allowed CI servers to test individual features in isolation before they hit the main codebase, enabling rapid, safe deployments.

The DVCS War

Why Did Git Beat Mercurial?

In 2005, Git and Mercurial were released weeks apart. Mercurial was generally considered easier to use and better documented. So why did Git win 95% of the market?

🐧

The Linux Pedigree

Git was built for the Linux kernel. It proved immediately that it could handle the largest, most complex software project on Earth. This gave it massive technical credibility.

🐙

GitHub

In 2008, GitHub launched (for Git only). It popularized "social coding" and the Pull Request. Mercurial's equivalent (Bitbucket) came slightly later and didn't capture the open-source community's heart.

🔧

Flexibility (Rebase)

Mercurial's "safe" philosophy restricted developers. Git's philosophy was "give users sharp tools." Advanced users loved Git's ability to rewrite history and curate perfect commits via the staging area.

📉
The end of Mercurial: By the mid-2010s, Git's network effect was unstoppable. In 2020, Bitbucket (originally built for Mercurial) officially dropped support for Mercurial entirely, signaling the final end of the DVCS war.

Summary

Key Takeaways — Lecture 14

Today we looked at the specific mechanics of the three most important VCS tools in software history.

01

SVN (Subversion)Centralized VCS. svn commit goes straight to the server. Branches are heavy directory copies. Requires network access to view history.

02

Mercurial (Hg)Distributed, written in Python, clean UI, safe by default. Uses hg pull and hg push. Lost the war but was deeply influential.

03

GitDistributed, incredibly fast, snapshot-based. Relies on the Staging Area, lightweight branches, and local history rewriting.

04

The Shift to DVCSDVCS eliminated the fear of breaking the build, allowing micro-commits, cheap branches, and eventually enabling modern CI/CD.

05

Git's VictoryGit won due to its performance handling the Linux kernel, its extreme flexibility for power users, and the massive network effect of GitHub.

06

Next: Unit IVWe will start getting deeper into advanced Git concepts, branching strategies (GitFlow), and how code merges integrate into CI/CD pipelines.

🎯
Exam tip: Be able to compare the commands: svn commit (goes to server) vs git commit (stays local). Know what the Git Staging area is (Mercurial and SVN don't have it). Understand why Git's branching is considered "cheap" compared to SVN.